This paper has been downloaded from the Building and Environmental Thermal Systems

Research Group at Oklahoma State University (www.hvac.okstate.edu)

The correct citation for the paper is:
Fisher, D.E., R.D. Taylor, F. Buhl, R.J. Liesen, R.K. Strand. 1999. A Modular, LoopBased Approached to HVAC Energy Simulation and Its Implementation in EnergyPlus.
Proceedings of Building Simulation '99, Vol. 3, pp. 1245-1252.

A MODULAR, LOOP-BASED APPROACH TO HVAC ENERGY SIMULATION AND

ITS IMPLEMENTATION IN ENERGYPLUS
Daniel E Fisher1, Russell D. Taylor2,
Fred Buhl3, Richard J Liesen2, and Richard K Strand4

systems as either monolithic blocks of code or as a

collection of tightly coupled and specialized
component based subroutines. This approach is
advantageous because it allows the solution method
to be tailored to each component and system type.
This results in models that tend to be quite robust. In
addition, a system-based approach simplifies the
input required to describe a particular system or
component since much of this information is built in
to the structure of the code itself.

ABSTRACT
This paper presents the new EnergyPlus HVAC
simulation environment, which differs from existing
energy analysis programs in three key respects. First,
the EnergyPlus HVAC simulation is based on a
"manager-interface" protocol that supports multiple
solution techniques within the overall context of the
simulation.
Second, the EnergyPlus HVAC
simulation
is based on high level component
connectivity. Third, the EnergyPlus simulation and
component modules enforce a high degree of data
encapsulation.
These three features together with
input and output processing services provided by the
environment result in a simulation tool that is ideally
suited for collaborative development of component
models, evaluation of solution techniques and design
of HVAC sub-systems. The paper describes the
features of the simulation environment, discusses
currently implemented algorithms and includes an
example of the type of results that can be expected.

On the other hand, there are a number of

disadvantages to a system based simulation approach:
New models are difficult to develop and
implement since this requires a working
knowledge of a significant fraction of the
program data structure and subroutine hierarchy

Existing models are difficult to change and

modifications can significantly alter the
technique required to obtain a solution

System based simulations are inflexible and often do

not
sufficiently
represent
the
significant
characteristics of the system or component being
modeled.

INTRODUCTION
Existing building energy simulation programs can be
broadly categorized on the basis of overall structure
as either system based, component based or equation
based. System based programs tend to use structured
languages such as FORTRAN to describe the various
system simulation algorithms. Since each algorithm
is tightly coupled with a numeric solver; usually a
Gauss-Seidel, successive substitution method
[Stoecker, 1989a], modifications to existing systems
tend to be difficult. Component and equation based
systems are more amenable to object based languages
and usually implement a Newton type solver,
[Stoecker, 1989b] that is de-coupled from the
component level algorithms or equations. Both
system based approaches and component or equation
based approaches have distinct advantages and
disadvantages.

Programs such as HVACSIM+ [Park, 1985],

TRNSYS [Klein, 1976], ESP-r [Clarke, 1996],
SPARK [Sowell, 1995] and IDA [Sahlin, 1991]
model HVAC systems and mechanical equipment at a
component or equation level. Complete systems are
defined by the relationship between components or
equations. As might be expected, this approach
makes it possible to develop a wide range of new
systems by connecting different combinations of
components or by connecting components in different
orders. A sophisticated numeric solver is required to
obtain a simultaneous solution among all the
simulation elements. In addition, there are a number
of potential disadvantages to a component or
equation based approach:

Building energy simulations, such as BLAST [BSO,

1989], IBLAST [Taylor, 1990, 1991] and DOE-2
[LBNL, 1989] can be described as system based
simulations. These programs model mechanical
1.
2.
3.
4.

Both the solvers and the language require

uniform (often high) model granularity.
Complex component connections must typically

Department of Mechanical and Aerospace Engineering, Oklahoma State University, Stillwater, OK, USA
Building Simulation Laboratory, University of Illinois at Urbana-Champaign, IL, USA
Lawrence Berkeley National Laboratories, Berkeley, CA, USA
School of Architecture, University of Illinois at Urbana-Champaign, IL, USA
1

be developed and specified as simulation input.

[Vuolle, 1997].

type and order in which components are specified on

each loop determines the system type.

The solution techniques used in component and

equation based approaches tend to militate
against the encapsulation of data. The tendency
toward global data structures directly and
adversely affects the extensibility and
maintainability of the code [McConnell 1993]

Each fluid loop is separated into two logical

simulation blocks. A schematic of a simple plant
loop is shown in Figure 1. Two managersa
demand side manager and a supply side
managercontrol the simulation of the loop.

The programs are typically constructed around a

single solver. As a result all sub-systems of the
simulation must be specified and solved to a
similar level of detail.
Tailoring solution
techniques to specific sub-systems is usually
difficult or impossible.

D E M A N D S IDE

S UPPLY S IDE

Pump

Chiller

Coil

The EnergyPlus HVAC simulation environment is a

hybrid implementation of component based and
system based environments. The presence of a fluid
loop, which is an abstract representation of a piping
or duct system, provides the structural framework
characteristic of system based models. The presence
of system components, which are both described and
connected to the loop in the simulation input,
provides the flexibility characteristic of component
based models.

Figure 1. Plant Loop Schematic

The nodes at the interface of the demand and supply
sides represent two images of the plant loop state
variables at the interface location. This dual image of
the data allows for the independent simulation of the
supply and demand sides and provides a means of
checking convergence between the two sides.
The air handling system and the zones it serves define
the air loop; a simple example representing a terminal
reheat system is shown in Figure 2. The reheat coils
and other components such as, VAV dampers and
mixing boxes, which are typically controlled on the
basis of zone simulation variables, are simulated on
the zone equipment side of the loop. Once again
interface nodes and component inlet and outlet nodes
completely specify the conditions in the loop.

The EnergyPlus HVAC simulation is based on fluid

loops and the ability to track fluid properties around
each loop by using loop nodes. The simulation is
controlled by loop managers which handle
initialization, check for convergence and control the
simulation of loop components or sub-systems. The
loop and loop node specification will support both
Newton-Raphson and successive substitution solvers.
The fluid loops and modular, input-connected
components support a manager-interface simulation
protocol. This protocol allows for the independent
simulation of sub-systems and facilitates the
development of customized solution procedures that
are a blend of system based and component based
solvers. For example, a SPARK or TRNSYS
solution to a particular sub-system can be supported
without affecting the system based solution schemes
utilized in other sub-systems.

Fan

Zone

Cooling
Coil
A IR L O O P
S IDE

Reheat
Coil

ZONE
E QUIPMENT
S IDE

MANAGER-INTERFACE PROTOCOL
Fluid loops and the ability to track fluid properties
around each loop by means of loop nodes are key
concepts in the EnergyPlus HVAC and mechanical
systems simulation. Systems are defined by first
specifying hydronic and air loops that represent the
ducts and pipes found in a physical system.
Components such as fans, dampers, coils, boilers and
chillers (or potentially groups of system components
such as an HVACSIM+ sub-system) are added to the
loops to form a complete system description. The

Figure 2. Air Loop Schematic

The manager-interface protocol establishes the
direction of flow in each loop, enforces the loops
convergence criteria, and updates loop node setpoint
information.
Each loop manager controls the
simulation of the components attached to its side of
the loop independently of the other managers. The
interface passes the most recent state variable
2

High level component connectivity is achieved by

assigning an inlet and outlet node to each component
and enforcing a standard protocol for retrieving and
updating information in the loop node data structure.
The loop nodes to which the component is connected
are specified as component inlet and outlet nodes as
shown in Figure 4. The node data structure connects
component models at the loop level, not at the
simulation variable level.
This important
simplification significantly reduces the complexity of
component model input at the expense of a small
reduction in system configuration flexibility.

information from the outlet of one loop to the inlet of

its companion loop.
There are several important benefits of the managerinterface protocol. It supports a diverse simulation
texture allowing different types of models and solvers
to be implemented within the domain of the various
managers. It also simplifies the developers task by
limiting the scope of the code he must master in order
to successfully implement a new model. Finally, the
manager-interface protocol supports the links to
external subsystem solvers.
A high level manager successively calls the loop
manager until the entire system has converged. This
high level solution scheme is based on the IBLAST
scheme of an adjustable system time step [Taylor,
1991].
The high level manager shortens the
simulation time step until overall stability criteria are
satisfied. Each loop manager sets simulation flags
that are used to share overall convergence
information with the other loop managers and the
high level simulation manager. The high level
manager successively calls the loop managers until
the simulation flags indicate that the entire simulation
has converged.

Outlet Node
Inlet Node

Figure 4. Fan Component Connections

Simulation of the component involves calculating the
fluid properties at the outlet node based on the inlet
node conditions and the operating characteristics of
the component itself. The manager-interface protocol
supports a wide range of component model types,
ranging from performance models based on operating
data to first principle models based on fundamental
thermodynamic equations. This flexibility in the
specification and support of component models is a
result of the fact that each loop may have its own
solverpotentially, its own set of solvers.
Component models on a loop must be compatible
with the loop solver, but are not constrained by
unwieldy global data structures, other component
models or the requirements of a general simulation
solver.

COMPONENT CONNECTIVITY
Components are connected to each other and to the
fluid loop at loop nodes, which are defined as points
on a loop where fluid properties are known and
available. The loop node data structure shown in
Figure 3 is a de-facto component interface.
TYPE NodeData
CHARACTER(len=Max) :: FluidType
REAL
:: Temp
REAL
:: TempMin
REAL
:: TempMax
REAL
:: TempSetPoint
REAL
:: MassFlowRate
REAL
:: MassFlowRateMin
REAL
:: MassFlowRateMax
REAL
:: MassFlowRateMinAvail
REAL
:: MassFlowRateMaxAvail
REAL
:: MassFlowRateSetPoint
REAL
:: Quality
REAL
:: Press
REAL
:: Enthalpy
REAL
:: HumRat
REAL
:: HumRatMin
REAL
:: HumRatMax
REAL
:: HumRatSetPoint
END TYPE NodeData
Figure 3. Loop Node Data Structure

DATA ENCAPSULATION
The modular structure of the simulation code and
services provided by the EnergyPlus Input Processor
support a high level of data encapsulation. A module
is defined as a self-contained set of initialization,
computation, control and node update routines. The
modules initialization routines use the Input
Processor to retrieve input data needed by the module
and populate module level data structures.
In general the input format is similar to the module
level data structure that it fills. For example, the
input format for plant loop parameters is shown in
Figure 5 where an A prefix indicates an alpha input
and a N prefix indicates a numeric input. The loop
name, fluid type, component list names and operation
scheme identifiers are shown in A1-A5). Design flow
rates and temperatures for the loop follow in A6-N4.

Fluid type, mass flow rate and standard

thermodynamic properties (temperature, pressure,
quality, enthalpy, and humidity ratio) are defined at
each point. In addition flow rate and set point
parameters are attached to the nodes.
3

which part of that structure is applicable to his

module. Modifying or extending an existing data
structure is also simplified by the narrowly defined
scope of the simulation variables. Similarly, adding a
new data structure with its associated input becomes a
trivial task. Finally, errors associated with the
modification or extension of existing data structures
are contained in a single module and cannot be
propagated to other simulation modules.

Finally, loop connections are defined by the inlet and

outlet node numbers designated N5-N9. ) and
PLANT LOOP,
A1 [Plant Loop Name],
A2 [fluid type],
A3 [Demand Side Components],
A4 [Supply side components],
A5 [Plant Operation Scheme],
A6 [Loop Temp Setpoint Schedule],
N1 [Maximum Loop Temperature],
N2 [Minimum Loop Temperature],
N3 [Loop Vol. Flow Rate SetPt.],
N4 [Max Loop Vol Flow Rate],
N5 [Min Loop Vol Flow Rate],
N6 [Supply Side Inlet Node],
N7 [Supply Side Outlet Node],
N8 [Demand Side Inlet Node],
N9 [Demand Side Outlet Node];
Figure 5. Plant Loop Specification

BETA IMPLEMENTATION
A beta version of EnergyPlus has been developed
with successive substitution solvers implemented in
each of the loop managers. Both rule based
controls and ideal controllers that are tailored for
specific applications are supported by the
implementation. Detailed representations of actual
controllers that can be applied to specific types of
components are not supported.

The component lists show the component type, name

and loop node connections. The type and order in
which components are specified on each loop
determines the system type. This information fills
analogous data structures in the plant loop manager
and condenser loop manager modules.

Two levels of Air loop control have been

implemented with the solution scheme. First, there is
a high level controller, the Setpoint Manager, which
sets the desired conditions at nodes around the air
handling system loops according to parameters and
schedules specified by the user. There is also a lower
level of control that simulates ideal system controllers
by acting on the inlet flow conditions to individual
system components.

Components are generally grouped by type in

simulation modules.
A Component model
specification includes two identifiers (a keyword and
a unique component name), all input parameters
required by the component algorithm and the
component loop connections.

An application of this type of controller is one that

sets the coil outlet air temperature by varying the inlet
water flow rate as shown in Figure 7.

Figure 6 shows the input specification for a simple

chiller.
The last four numeric inputs are the
component loop connections. In this case, the
component is connected to two fluid loopsa
condenser loop and a plant loop. This structure is
reflected by a derived type in the Chiller simulation
module.

Sensed
Node

CHILLER:CONSTANT COP,
A1 [Chiller Name],
N1 [Nominal Capacity],
N2 [COP],
N3 [Design Evap. Flow Rate],
N4 [Design Cond. Flow Rate],
N5 [Plant Loop Inlet Node],
N6 [Plant Loop Outlet Node],
N7 [Condenser Loop Inlet Node],
N8 [Condenser Loop Outlet Node];
Figure 6. Component Model Specification

Control
Valve
Actuated
Node

Cooling
Coil Air
Inlet
Figure 7. Cooling Coil Control
Air loop controllers update the value of the actuated
variable using previous values of the sensed and
actuated values modified by a pre-set, normalized
gain.

The high level of data encapsulation achieved by the

Energy Plus modular structure is advantageous for
several reasons. Extending or modifying an existing
computational module is greatly simplified by the fact
that local rather than global data structures are
defined, populated and used by the developer. The
developer is spared the sometimes daunting task of
deciphering a large global structure and determining

Currently the plant loop manager, the condenser loop

manager and the zone equipment manager use rulebased schemes to operate the loop equipment.
Although these managers will support componentbased controls, the performance based models
4

to 22C during the day with a nighttime setback to

18C. The decrease in the daytime heating load is
due to the presence of scheduled internal heat gains.
During the summer design day, the zone was
controlled to 24C during the day with a nighttime
setback to 35, although the cooling coil was also
scheduled off during this period. As can be seen from
the results shown in the figures, the system is able to
control the zones to the desired temperature very
accurately. Other features of note are the large pickup loads that occur when the system comes out of
setback around hour 8 of the simulation (7am).

currently implemented in EnergyPlus cannot support

a detailed component control algorithm.
For Example, performance based plant models are
suited only for ideal control based on their part load
performance or for a load range based scheme that
specifies the operating sequence of the equipment in
the simulation input. Figure 8 shows how a plant
operation scheme is specified in input. The upper
and lower limits of the load range and the name of the
load range equipment list are specified under the
Load Range Based Operation keyword.
The
equipment in each list is specified under the Load
Range Equipment List keyword. Equipment is listed
in order of operating priority (from highest to lowest).

The second example, for which results are given in

Figures 11 and 12, uses the same three zones as in the
previous case but now served by a Variable Volume
system with reheat coils on each zone to adjust the
supply air temperature. Again, the zone temperatures
are controlled very accurately and with stability. Note
that for the summer design day, zone 1 does
experience some reheat coil energy use presumably
because it has the least thermal mass of the three
zones.

LOAD RANGE BASED OPERATION,

A1 [Name of Operation Scheme],
N3 [Upper], N4 [Lower], A5 [List],
N3 [Upper], N4 [Lower], A5 [List],
N3 [Upper], N4 [Lower], A5 [List],
LOAD RANGE EQUIPMENT LIST,
A1 [Equip List Name],
A4 [Equip Type], A5 [Name],
A4 [Equip Type], A5 [Name],
Figure 8. Plant Operation Input Specification

SUMMARY AND CONCLUSIONS

The EnergyPlus HVAC simulation environment
provides a context for implementation and
development of a range of solution techniques and
component models. The manager-interface protocol
provides the high level structure and control
necessary to achieve overall convergence of the
simulation.
The loop-node definition enforces
straightforward coupling of components to form
various system configurations, and a well defined
local data structure and input processor limit the
scope of simulation variables and facilitate extension
and modification of the simulation modules.

The zone equipment, following a traditional system

based simulation model, uses the zone load as the
sensed control variable.
The sensed load is
calculated based on the zone air setpoint temperature,
which is a user input and equivalent to a thermostat
within the zone. In the zone equipment simulation,
the system heating or cooling output to the zone is
calculated and compared to the zone load, which is
also effectively the required system output. As in the
air loop simulation, controllers are used to adjust the
operation of the zone equipment components so that
the difference between the actual and required system
outputs is minimized. Once the system output is
calculated on this basis, it is used in the zone air heat
balance to update the zone air temperature.

Researchers, developers and users will all benefit

from the unique features of the environment.
Researchers and developers can focus on an area of
interest in one loop manager without affecting
solution techniques or data structures in other loop
managers.
Component model compatibility is
enforced only at the loop manager level allowing for
various types of models in the various loop managers.
Input processing services are readily available and
easily implemented.
The overhead normally
associated with extending an input language is
virtually eliminated in the EnergyPlus environment.
Users will find the EnergyPlus input files to be both
readable and organized in a logical fashion. The
current implementation, in the tradition of IBLAST
and DOE-2, requires the same type of input with
additional information to define loops, nodes and
controls.

EXAMPLES
In the following examples, each loop is simulated by
stepping around the loop, in the flow direction, from
one component to the next. In the first example, for
which results are presented in Figures 9 and 10, a
three zone building served by a constant volume dual
duct system was simulated. The system consisted of
a single fan upstream of a splitter. One branch of the
splitter fed into a cooling coil, the other into a heating
coil. Each coil was controlled to a constant outlet
temperature by adjusting the supply water flow rates.
On the zone side of the system, each zone had a
mixing damper that provided air at a temperature
appropriate for the load experienced by the zone.
During the winter design day, the zone was controlled

A short-time step, successive substitution scheme that

makes use of the inherent structure of an HVAC
fluid loop in defining system models has been
implemented. In this implementation, loop managers
utilize both rule-based control algorithms and ideal
controller models to control the simulation of
equipment components.

Stoecker, W.F. Design of Thermal Systems, Third

Edition, McGraw Hill, New York, New York, 1989a,
p332-334

Continued development of the environment is the

subject of an ongoing investigation. The examples
presented in this paper, which demonstrate the
performance of a constant volume dual duct system
and a variable air volume system, are representative
of the type of simulation results one can expect from
the Beta Implementation of EnergyPlus

Taylor, R. D., C.O. Pedersen, D.E. Fisher, R. J.

Liesen, L.L. Lawrie, Simultaneous Simulation of
Buildings and Mechanical Systems in Heat Balance
Based Energy Analysis Programs, Proceedings of the
3rd International Conference on System Simulation in
Buildings, Liege, Belgium, December 3-5, 1990.

Stoecker, W.F. Design of Thermal Systems, Third

Edition, McGraw Hill, New York, New York, 1989b,
p123-126

Taylor, R.D., C.O. Pedersen, D.E. Fisher, R. J.

Liesen, L.L. Lawrie, Impact of Simultaneous
Simulation of Buildings and Mechanical Systems in
Heat Balance Based Energy Analysis Programs on
System Response and Control, Conference
Proceedings IBPSA Building Simulation '91, Nice,
France, August 20-22, 1991.

ACKNOWLEDGEMENTS
The authors wish to acknowledge of the Building
Technology Group in the Department Of Energy for
the continued support of this project.

Vuolle, Mika, Axel Bring, An NMF Model Library

for Building Climate and Energy Simulation, Fourth
International Conference Proceedings IBPSA
Building Simulation '97, Prague, Czech Republic,
September
8-10,
1997,
p181-187.

REFERENCES
BSO, BLAST Technical Reference Manual, BLAST
Support Office, University of Illinois, 1991.
Clarke J A The ESP-r System: Advances in
Simulation Modelling, Building Services Journal,
pp27-9, May 1996
Klein, S.A., W.A. Beckman and J.A. Duffie,
TRNSYSA
Transient
Simulation
Program,
ASHRAE Transactions 82 (1), 1976, p 623-633
LBNL, DOE-2 Reference Manual, Lawrence
Berkeley Laboratory and Los Alamos Scientific
Laboratory, May 1980.
McConnell, S.C. Code Complete, Microsoft Press,
Redmond, Washington, 1993, p. 118
Park, C., D.R. Clark and G.E. Kelly, An Overview of
HVACSIM+, A Dynamic Building/HVAC Control
Systems Simulation Program, First Building Energy
Simulation Conference
Proceedings,
Seattle,
Washington, USA, IBPSA, 1985
Sahlin, P. and A. Bring. IDA SolverA Tool for
Building and Energy System Simulation, Conference
Proceedings IBPSA Building Simulation '91, Nice,
France, August 20-22, 1991. p339-348
Sowell, E. F., M.A. Mosier, HVAC Component
Model Libraries For Equation-Based Solvers, Fourth
International Conference Proceedings IBPSA
Building Simulation '95, Madison, Wisconsin, USA,
August 14-16, 1995, p189-196.

ADDITIONAL FIGURES
50

24.0

45
40

22.0

35

25
20

18.0

15
10

16.0

5
14.0

0
0

12

16

20

24

Hour

Zone 1 Air Temp (C)

Zone 3 Air Temp (C)

Zone 2 Air Temp (C)

Hot Water Coil Heating Rate (kW)

Figure 9. Dual Duct System Response Winter Design Day

3.60E+01
2.00E+01
3.40E+01

3.20E+01

3.00E+01

1.00E+01

2.80E+01

2.60E+01
5.00E+00
2.40E+01

2.20E+01

0.00E+00
0

12

16

20

Hour

Zone 1 Air Temp (C)

Zone 3 Air Temp (C)
Chilled Water Coil Sensible Cooling Rate (kW)

Zone 2 Air Temp (C)

Hot Water Coil Heating Rate (kW)

Figure 10. Dual Duct System Response Summer Design Day

24

Kilowatts

1.50E+01

Kilowatts

30

20.0

8.00

20

6.00

18

4.00

16

2.00

14

Kilowatts

22

0.00
0

12

16

20

24

Hour

Zone 1 Air Temp (C)

Zone 3 Air Temp (C)
Zone 2 Reheat Coil Heating Rate (kW)

Zone 2 Air Temp (C)

Zone 1 Reheat Coil Heating Rate (kW)
Zone 3 Reheat Coil Heating Rate (kW)

Figure 11. VAV System Response Winter Design Day

2.50E+01

36

34
2.00E+01
32
1.50E+01

Kilowatts

30

28

1.00E+01

26
5.00E+00
24

22

0.00E+00
0

12

16

20

Hour

Zone 1 Air Temp (C)

Zone 3 Air Temp (C)
Chilled Water Coil Sensible Cooling Rate (kW)

Zone 2 Air Temp (C)

Zone 1 Reheat Coil Heating Rate (kW)

Figure 12. VAV System Response Summer Design Day

24