EnergyPlus



EnergyPlus
Developer's
License		 EnergyPlus
Technical
Reports


 
Overview of EnergyPlus
by
C.O. Pedersen, D.E. Fisher, R.J. Liesen, R.K. Strand and R.D. Taylor
University of Illinois at Urbana-Champaign


W.F. Buhl and F.C. Winkelmann
Lawrence Berkeley National Laboratory

L.K. Lawrie
US Army Construction Engineering Research Laboratories

D.B. Crawley
US Department of Energy
 
The Federal Government, as the largest owner and operator of buildings in the United States, has long been aware of the importance of energy conscious building design and operation. Energy conscious engineering has the potential to save building owners and tenants millions of dollars and contribute to the conservation of vital natural resources. In an effort to promote energy efficiency, both DOD and DOE have separately funded the development of building energy analysis tools since the 1970s.
 
At the outset, both research efforts charted separate courses toward the same goal: a robust and comprehensive building energy analysis program. There was no way of knowing a priori which path would achieve the goal; therefore, it was prudent to fund multiple development efforts toward the same end. As it turned out, both research projects succeeded in producing useful energy analysis tools. The DOD effort produced the Building Loads Analysis and System Thermodynamics (BLAST) program that has its origins in the NBSLD program developed at the US National Bureau of Standards (now NIST). The DOE effort produced the DOE-2 program that has its origins in the Post Office program written for the US Post Office. The two programs are comprised of hundreds of subroutines each designed to solve a specific problem in achieving the overall goal. In some cases, the subroutines developed by the DOE-2 team were more accurate. In other cases, the subroutines developed by the BLAST team were more accurate.
 
The name chosen for the new program is EnergyPlus. The goal is to take the best features and capabilities of BLAST and DOE-2 and combine them in a new program. Many new building technologies that cannot be evaluated by either BLAST or DOE-2 will be accessible with the new tool. In addition, a number of building simulation models that today can only be used by researchers will be included in the new program.
 

The Structure of EnergyPlus


Overall Program Structure
EnergyPlus will be structured using a free-format input file that contains a complete object-based description of the building and HVAC systems.
 
The building simulation will be based on the heat balance engine from IBLAST, a research version of BLAST with HVAC systems integrated into the building simulation. In order to provide maximum flexibility, an HVAC engine will be developed to handle the communication between the heat balance engine and the various HVAC modules, including SPARK andTRNSYS systems, and other systems that may be developed in the future. The HVAC manager will also manage data communication between the HVAC modules and the input and output data structures.
Figure 1:   EnergyPlus Simulation Overview

 

 
The calculation engine will write results into an output data structure accessible to output post-processing agents. The output data structure will be simple yet complete so that interface developers can easily access the results of the simulation without modifying the calculation engine. The overall program structure is summarized in Figure 1.

Solution Technique: Integrated Simulation
There is strong consensus in the design community that a tool with additional capabilities is needed. Recent user surveys by both DOE and DOD indicated strong support for the project. This is in large part due to the inclusion of integrated simulation capabilities in the new program. EnergyPlus will utilize the IBLAST integrated solution technique to correct the most serious deficiency of the BLAST and DOE-2 sequential simulations - the inaccurate prediction of space temperatures. Accurate prediction of space temperatures is crucial to energy efficient system engineering. System sizes, plant sizes, occupant comfort and occupant health are all dependent on space temperatures.
 
Integrated simulation allows engineers and architects to evaluate a number of energy saving measures that cannot be simulated adequately with either DOE-2 or BLAST. These include:
 
Program Elements to be Included
In addition to providing users the capability of using either BLAST or DOE-2 input formats, EnergyPlus will incorporate features from both programs into the calculation engine, as shown in the following table
 
Source of EnergyPlus Program Elements
Concepts to be taken from IBLAST
Simultaneous Solution Technique
Combined Heat and Mass Transfer
Radiant Heating and Cooling
System and Plant Models 		Heat Balance Engine
Interior Convection
MODSIM Connection
Atmospheric Pollution Calculation 		Coil Models
Internal Mass
Thermal Comfort
Concepts to be taken from DOE-2
Daylighting
System and Plant Models
Input Function Capability 		Window Shade Mgt
Switchable Glazing
Atmospheric Pollution Calc 		Advanced Fenestration
Sky Models
New Features
HVAC Water and Air Loops Interzone Airflow
Implied New Programming for Infrastructure
New Reporting Mechanism

 
Simulation Management
At the outermost program level, a Simulation Manager Module (shown schematically in Fig. 2) controls the entire loop structure of the simulation. This includes all of the simulation loops from the sub-hour level up through the complete simulation period, which may be a season or a year or several years. The actions of the individual simulation modules are directed through simulation status flags. These flags tell the simulations to take certain actions such as initialization, reporting or record keeping.
 
The Heat and Mass Balance Engine
The EnergyPlus program will incorporate a heat balance model for building thermal zone simulations. Several fundamental assumptions are implied in the formulation. The most fundamental of these is that the air in the thermal zone can be modeled as well-stirred. This means it has a uniform temperature throughout the zone because it mixes by motion within itself. There is ongoing research into more complex models lying somewhere between the well stirred model and a full CFD calculation. The EnergyPlus modular structure will allow these models to be included into an energy simulation so their overall effect on can be evaluated from different viewpoints.
 
The other major assumption in the current heat balance model is that the surfaces of the room (walls, windows, floor, etc.) can be treated as entities having:
  • uniform surface temperatures,
  • uniform long and short wave irradiation,
  • diffuse radiating surfaces, and
  • one-dimensional heat conduction.

Within the framework of these assumptions, the current heat balance model can be constructed out of four distinct processes:
  • The outside face heat balance.
  • The wall conduction process.
  • The inside face heat balance.
  • The air heat balance.
Figure 2:    Simulation Manager
 

 

 
The air heat balance also implies an air mass balance which takes into account various mass streams (exhaust air, infiltration, etc.). The relationships between the four fundamental processes are shown schematically in Fig. 3. Each of the fundamental processes is shown in a rounded box in the figure. The energy flow is indicated with arrows. If an energy exchange is taking place, the arrows point in both directions.

The processes depicted in Fig. 3 are for an opaque surface. A transparent surface would be similar except the absorbed solar energy would be split into an inward and an outward flowing fraction. These, in turn, would participate in the corresponding surface heat balances. Except for the air heat balance, the processes shown are repeated for each surface in the space. 		Figure 3:    Heat Balance Solution Technique
 

 
 

 
The HVAC Engine
The sequential simulation of building, air distribution system and central plant found in DOE-2 and BLAST imposes rigid boundaries on the program structures. The simultaneous solution technique used in EnergyPlus allows for the redrawing of those boundaries.
 
The schematic in Fig. 4 visualizes a typical system in the context of the EnergyPlus simulation. The HVAC systems have been divided into three blocks on the basis of information flow. The goal was to minimize the information flow paths between blocks so that data could be localized to the greatest extent possible. The heat extraction block represents the interaction with the heat balance engine. This is indicated by the squares labeled "zones". The schematic shows only two zones per system type, and two system types, but these numbers can be increased arbitrarily. The information that is passed between the interface block and the heat extraction block consists of airflow rates, enthalpies, and temperatures. This is the information needed by the air balance part of the heat balance engine. 		Figure 4:     Schematic of Representative HVAC Simulation
 


The supply component block contains the code to simulate the primary energy components such as boilers and chillers. Again, the information passed to the interface block consists of flow rates and temperatures of a fluid which could be water, brine, refrigerant or other heat transfer medium.
 
The interface block contains the routines necessary to simulate the pumps, fans, coils, and airflow control devices. Of these, the coil simulation is the most difficult, and a modular structure within the block allows alternative coil models to be substituted easily.
 
The EnergyPlus HVAC simulation will be based on "water distribution loops" and "air distribution loops" rather than equipment types. This structure results in a blurring of the traditional boundaries between the building, the air distribution system and the central plant.
 
Software Development Plan

 
Programming Goals
FORTRAN90 (F90) was selected as the programming language for EnergyPlus for two reasons:
* Both BLAST and DOE-2 were written in previous versions of FORTRAN. Thus the code can move by evolution to the new language.
* F90 allows movement toward an object-based simulation by providing a modular structure.

 
In the context of this development, F90 refers to the full American National Standard FORTRAN 90 language as defined in the American National Standard Programming Language FORTRAN 90, ANSI X3.198-1992 and International Standards Organization Programming Language FORTRAN, ISO/IEC 1539:1991(E). Two subclasses of code will be allowed in the program:
 

FORTRAN90 Strict Code that adheres to at least the FORTRAN77 standard and includes all new features of FORTRAN90.
FORTRAN90 Pure Code that does not contain any of the features which have been ruled obsolete by the FORTRAN90 standard.

Three types of code may coexist in any particular version of the program at one time:


Legacy Code Program code from IBLAST and DOE-2 that will be rewritten, but without algorithm changes, for reasons of time constraints, testing considerations, etc.
Reengineered Code Concepts that have been reengineered based on first principles and then modified to fit the proposed guidelines agreed upon by the team members. The starting point for reengineered code is capabilities from either IBLAST or DOE-2.
New Code

 
However, while these types of code will coexist in the EnergyPlus source, different expectations on the relative "purity" of the code will be enforced. All legacy code that is included in EnergyPlus must be at least F90 strict. Mildly reengineered code (near legacy) which has not undergone any algorithm changes (only inclusion in a module, renaming of variables, etc.) will be allowed as long as it conforms to the F90 strict test. Reengineered code that has been modified significantly and all new code will be required to conform to the F90 pure standard.
 
Modularization of the Code
In order to make it easy to extend the basic capabilities of EnergyPlus, the developers are following a modularization process that results in a more object-oriented structure. Three types of modules are being used: modules that contain data only, modules that contain both data and procedures, and some modules that only contain procedures. The data-only modules are used to make global data available to modules throughout the code. The data-plus-procedure modules are the workhorses of the simulation, and the procedure-only modules supply utility functions. In order to make the modularization possible it is necessary to incorporate a series of manager modules whose function it is to control the overall execution of the program. One of these modules, the simulation manager was described previously.
 
The Re-engineering Process