The Input Data File (IDF) is the file containing the data
for an actual simulation. This file is also a text (ASCII)
file with a syntax “filling in the blanks” of the definitions
in the IDD. A portion of an IDF with input data for the hot
water coil defined in the IDD example looks like:
Coil:Heating:Water,
SPACE1-1 Zone
Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule
Name
autosize, !- U-Factor Times Area Value
{W/K}
autosize, !- Maximum Water Flow Rate
{m3/s}
SPACE1-1 Zone
Coil Water In Node, !- Water Inlet Node Name
SPACE1-1 Zone
Coil Water Out Node, !- Water Outlet Node Name
SPACE1-1 Zone
Coil Air In Node, !- Air Inlet Node Name
SPACE1-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance
Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water
Temperature {C}
16.6, !- Design Inlet Air
Temperature {C}
71.1, !- Design Outlet Water
Temperature {C}
32.2; !- Design Outlet Air
Temperature {C}
Coil:Heating:Water,
SPACE2-1 Zone
Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule
Name
autosize, !- U-Factor Times Area Value
{W/K}
autosize, !- Maximum Water Flow Rate
{m3/s}
SPACE2-1 Zone
Coil Water In Node, !- Water Inlet Node Name
SPACE2-1 Zone
Coil Water Out Node, !- Water Outlet Node Name
SPACE2-1 Zone
Coil Air In Node, !- Air Inlet Node Name
SPACE2-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance
Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water
Temperature {C}
16.6, !- Design Inlet Air
Temperature {C}
71.1, !- Design Outlet Water
Temperature {C}
32.2; !- Design Outlet Air
Temperature {C}
Coil:Heating:Water,
SPACE3-1 Zone
Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule
Name
autosize, !- U-Factor Times Area Value
{W/K}
autosize, !- Maximum Water Flow Rate
{m3/s}
SPACE3-1 Zone
Coil Water In Node, !- Water Inlet Node Name
SPACE3-1 Zone
Coil Water Out Node, !- Water Outlet Node Name
SPACE3-1 Zone
Coil Air In Node, !- Air Inlet Node Name
SPACE3-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance
Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water
Temperature {C}
16.6, !- Design Inlet Air
Temperature {C}
71.1, !- Design Outlet Water
Temperature {C}
32.2; !- Design Outlet Air
Temperature {C}
Each coil entry begins with the class name (keyword)
specifying the type of coil. Next is the coil name – a user
(or interface) created name that is unique within the given
class. Generally in EnergyPlus, objects within a class are
distinguished by unique names. The object name is usually the
first data element following the class name. Any alphanumeric
data item in the IDF can be up to 100 characters long. Any
characters past 100 are truncated (lost). After the object
name comes the real data. If we look at the IDD we see that
the first data item after the object name is expected to be an
alphanumeric – a schedule name. In the IDF, we see the
corresponding field is “ReheatCoilAvailSched”, the object name
of a schedule elsewhere in the IDF file. In EnergyPlus, all
references to other data entries (objects) are via object
names. The next two data items are numeric: the coil UA and
the maximum water mass flow rate. The final four items are
again alphanumeric – the names of the coil inlet and outlet
nodes. Nodes are used in EnergyPlus to connect HVAC components
together into HVAC systems.
The example illustrates the use of comments to create clear
input. The IDF is intended to be human readable, largely for
development and debugging purposes. Of course, most users
will never see an IDF – they will interact with EnergyPlus
through a Graphical User Interface (GUI), which will write the
IDF for them. However, a module developer is a special kind
of user. The module developer will need to create a portion
of an IDF by hand very early in the development process in
order to begin testing the module under development. Thus, it
is important to understand the IDF syntax and to use comments
to create readable test IDF files.
Summary
One of the early tasks of a module developer is to create
input (most likely by hand) for the new component and to
insert it into an existing IDF file in order to test the new
component model. The IDF syntax resembles the syntax for the
IDD. The data follows the IDD class description. Comments
should be used to make the IDF readable.
Input Data File[LINK]
The Input Data File (IDF) is the file containing the data for an actual simulation. This file is also a text (ASCII) file with a syntax “filling in the blanks” of the definitions in the IDD. A portion of an IDF with input data for the hot water coil defined in the IDD example looks like:
Coil:Heating:Water,
SPACE1-1 Zone Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule Name
autosize, !- U-Factor Times Area Value {W/K}
autosize, !- Maximum Water Flow Rate {m3/s}
SPACE1-1 Zone Coil Water In Node, !- Water Inlet Node Name
SPACE1-1 Zone Coil Water Out Node, !- Water Outlet Node Name
SPACE1-1 Zone Coil Air In Node, !- Air Inlet Node Name
SPACE1-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water Temperature {C}
16.6, !- Design Inlet Air Temperature {C}
71.1, !- Design Outlet Water Temperature {C}
32.2; !- Design Outlet Air Temperature {C}
Coil:Heating:Water,
SPACE2-1 Zone Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule Name
autosize, !- U-Factor Times Area Value {W/K}
autosize, !- Maximum Water Flow Rate {m3/s}
SPACE2-1 Zone Coil Water In Node, !- Water Inlet Node Name
SPACE2-1 Zone Coil Water Out Node, !- Water Outlet Node Name
SPACE2-1 Zone Coil Air In Node, !- Air Inlet Node Name
SPACE2-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water Temperature {C}
16.6, !- Design Inlet Air Temperature {C}
71.1, !- Design Outlet Water Temperature {C}
32.2; !- Design Outlet Air Temperature {C}
Coil:Heating:Water,
SPACE3-1 Zone Coil, !- Name
ReheatCoilAvailSched, !- Availability Schedule Name
autosize, !- U-Factor Times Area Value {W/K}
autosize, !- Maximum Water Flow Rate {m3/s}
SPACE3-1 Zone Coil Water In Node, !- Water Inlet Node Name
SPACE3-1 Zone Coil Water Out Node, !- Water Outlet Node Name
SPACE3-1 Zone Coil Air In Node, !- Air Inlet Node Name
SPACE3-1 In Node, !- Air Outlet Node Name
UFactorTimesAreaAndDesignWaterFlowRate, !- Performance Input Method
autosize, !- Nominal Capacity {W}
82.2, !- Design Inlet Water Temperature {C}
16.6, !- Design Inlet Air Temperature {C}
71.1, !- Design Outlet Water Temperature {C}
32.2; !- Design Outlet Air Temperature {C}
Each coil entry begins with the class name (keyword) specifying the type of coil. Next is the coil name – a user (or interface) created name that is unique within the given class. Generally in EnergyPlus, objects within a class are distinguished by unique names. The object name is usually the first data element following the class name. Any alphanumeric data item in the IDF can be up to 100 characters long. Any characters past 100 are truncated (lost). After the object name comes the real data. If we look at the IDD we see that the first data item after the object name is expected to be an alphanumeric – a schedule name. In the IDF, we see the corresponding field is “ReheatCoilAvailSched”, the object name of a schedule elsewhere in the IDF file. In EnergyPlus, all references to other data entries (objects) are via object names. The next two data items are numeric: the coil UA and the maximum water mass flow rate. The final four items are again alphanumeric – the names of the coil inlet and outlet nodes. Nodes are used in EnergyPlus to connect HVAC components together into HVAC systems.
The example illustrates the use of comments to create clear input. The IDF is intended to be human readable, largely for development and debugging purposes. Of course, most users will never see an IDF – they will interact with EnergyPlus through a Graphical User Interface (GUI), which will write the IDF for them. However, a module developer is a special kind of user. The module developer will need to create a portion of an IDF by hand very early in the development process in order to begin testing the module under development. Thus, it is important to understand the IDF syntax and to use comments to create readable test IDF files.
Summary
One of the early tasks of a module developer is to create input (most likely by hand) for the new component and to insert it into an existing IDF file in order to test the new component model. The IDF syntax resembles the syntax for the IDD. The data follows the IDD class description. Comments should be used to make the IDF readable.
Documentation content copyright © 1996-2026 The Board of Trustees of the University of Illinois and the Regents of the University of California through the Ernest Orlando Lawrence Berkeley National Laboratory. All rights reserved. EnergyPlus is a trademark of the US Department of Energy.
This documentation is made available under the EnergyPlus Open Source License v1.0.